With the proliferation of computers and the advent of the Internet, and in particular, the maturing of the World Wide Web (“web”), real-time conversations between conversation participants via their computer systems are becoming increasingly common. These conversations, which take place virtually over computer networks, are ever replacing the traditional face-to-face meetings.
Collaboration applications, such as MICROSOFT LIVE MEETING, are increasingly being used to conduct these virtual meetings between potentially geographically distributed people. For example, a meeting organizer can schedule a meeting with a collaboration service server, and provide a list of meeting participants. The meeting organizer then invites the participants to attend the scheduled meeting by sending those people invitations. The invitation contains privileged information, such as a meeting time, meeting location—i.e., a universal resource locator (URL), meeting identifier, and meeting password, the participant will need to attend the meeting.
These collaboration applications typically provide for multiple classes of participants. For example, one class of participants in a virtual meeting may be “presenters,” while another class of participants may be “attendees.” The classes of participants may be distinguished based on permissions, with presenters having permission to perform additional or more functionality during the meeting than attendees. To provide the different permissions, the collaboration application usually provides presenters with a different application view—user interface (UI)—than the application view that is provided to attendees.
One problem with providing different desktops to different classes of participants is that one class of participants, for example, presenters, often are not provided good feedback regarding the other classes of participants, for example, attendees, are seeing. For example, during the virtual meeting experience, attendees may not have permission to see all of the UI components that are available in a meeting to presenters. Thus, during voice conversations conducted in conjunction with the meeting, presenters may not know exactly what an attendee is able to see, and may get confused about what attendees can actually do.
Another problem arises where a view of a participant's desktop or a portion of the desktop is shared with the other participants in a collaboration session. For example, application sharing allows a specific presenter—e.g., host—to share some portion of his or her screen with the other participants in the meeting. The image that is being shared is made available via a connection, typically through a computer network, to the other participants' computer screens. Because the image that is being shared is made available by transmission from the application sharing host's computer to the other participants' computers, typically over a network, issues such as network transmission latencies and/or slowdowns and the difference in computer performance may cause some or all of the participants of the meeting to fall significantly behind what is being displayed to the host of the application sharing session. Thus, the presenter who is hosting the application sharing session has difficulty knowing what the other participants in the meeting are seeing.
It would be desirable to have a technique that allows one class of participants—i.e., presenters—in a collaboration session to have a view of what another class of participants—i.e., attendees—is visually experiencing during the collaboration session.